A. Technical Field
The present invention relates generally to voice communication across multiple networks, and more particularly, to providing a voice bridge that allows non-open settlement protocol (OSP) networks to interface with an OSP server and establish connections with both OSP and non-OSP networks.
B. Background of the Invention
The popularity of Voice over Internet Protocol (VoIP) is continually increasing. VoIP systems provide telephone connections by transmitting audio packets between two telephone devices via a packet-switched network (e.g., TCP/IP network). This increase in VoIP popularity is primarily due to two reasons: the relatively inexpensive cost and the increase in quality of VoIP communication.
VoIP allows service providers to offer long-distance services to clients at much lower rates than traditional phone companies. VoIP allows service providers a much more efficient use of networks than the traditional public switched telephone network used by the traditional phone companies. One reason for this increase in efficiency is the ability of VoIP to multiplex voice packets from multiple circuit-switched paths (i.e., telephone connections) together on a unified communications structure within a network. Thus, the bandwidth utilization increases within a packet switched network allowing more telephone connections to occur simultaneously.
A few years ago, the quality of a VoIP connection was lacking due primarily to packet delay occurring in the networks. This problem was primarily caused by the inefficiency of the Internet over which the VoIP connections occurred. Internet events such as bottlenecks and discarding packets reduced the quality of a conversation occurring across the Internet. However, the increase of large private networks, more controlled Internet backbones, and more efficient routing protocols have greatly reduced these problems. Thus, the quality of a VoIP telephone conversation today has drastically improved. As the popularity of VoIP continues to grow, other issues need to be addressed, such as systems that monitor call usage and authorization of VoIP connections between different networks. These systems are necessary to enable service providers to more effectively control and to monitor voice connections for purposes including client billing, network management, and expansion of network capacity.
Open Settlement Protocol (OSP) is a settlement protocol that provides call usage, authorization, routing and detail reporting among networking devices such as gateways, gatekeepers, and clearinghouse service providers. Technical specifications of the OSP protocol are described in “Open Settlement Protocol (OSP) for Inter-Domain pricing, authorization, and usage exchange,” available from the European Telecommunications Standards Institute, publication number ETSI TS 101 321, version 2.1.1 dated 08/2000, which is hereby incorporated by reference in its entirety. FIG. 1 illustrates a typical VoIP connection implemented using OSP. A first telephone 105 initiates the VoIP connection by transmitting a request to a first OSP gateway 120. Generally, this request includes a destination telephone number for the VoIP connection. This destination telephone number may be a ten-digit number if it is within the United States or may correspond to a number in a foreign country. The first OSP gateway 120 resides within a first OSP network 160 that can communicate and interface with other OSP compatible devices. This first OSP network 160 may also contain other OSP gateways 130.
Upon receiving the request, the first OSP gateway 120 transmits an authorization request to an OSP server 115 via line 155. This request generally includes the destination telephone number received from the first telephone 105 and may be formatted in XML. The OSP server 115 translates information within the request and returns an authorization reply that may contain routing information and a first OSP token. The routing information may be formatted in XML and transmitted using Secure Sockets Layer (SSL). This routing information generally includes an Internet Protocol (IP) address to a second OSP gateway 125 or an IP address to an OSP gatekeeper (not shown). If the routing information corresponds to an OSP gatekeeper, then an IP address to the second OSP gateway 125 that terminates the connection is retrieved from the first OSP gateway 120. Typically, such an occurrence may be necessary when other gateways 125, 135 also reside on the second OSP network 165.
The first OSP token transmitted from the first OSP gateway 120 is usually encoded (most often in base64) and may also be encrypted depending on the design of the system. This first OSP token is generally an opaque data string and is passed between domains to ensure proper authorization and communication between devices. The first OSP token is used by the first OSP gateway 120 to offer a connection to the second OSP gateway 125. Additionally, the first OSP token is used by the second OSP gateway 125 to accept the connection offer.
After the IP address of the second OSP gateway 125 is received from the OSP server 115, the first OSP gateway 120 establishes a connection with the second OSP gateway 125. The first OSP gateway 120 establishes this connection by transmitting a connection request and the first OSP token to the second OSP gateway 125. Because the second OSP gateway 125 is OSP compatible, it is able to decode and decrypt (if necessary) the first OSP token and retrieve necessary OSP information to terminate the connection and interface with the OSP server 115 accordingly. This connection is established after the second OSP gateway 125 accepts the connection request offered by the first OSP gateway 120. Typically, communication on this connection will follow the International Telecommunication Union (ITU) H.323 standard.
Once the connection between the first OSP gateway 120 and the second OSP gateway 125 is established, audio data is transmitted along a connection 180. Thus, an individual on the first telephone 105 is able to have a conversation with an individual on the second telephone 110 via this connection 180. The first and second OSP gateways 120, 125 monitor the VoIP call between the first and second telephones 105, 110. Data such as physical locations of the telephones 105, 110, the amount of time elapsed during the VoIP call, and the time at which the phone call occurred are monitored by each of the OSP gateways 120, 125. The first and second gateways 120, 125 report this call usage information to the OSP server 115 either intermittently during the phone call or after the phone call is completed. Specifically, the first OSP gateway 120 transmits this information to the OSP server 115 via line 155 and the second OSP gateway 125 transmits this information to the OSP server 115 via line 150. Thus, all of this call usage information as well as call authorization, described above, is maintained within a single location. As a result, the OSP server 115 may function as a clearinghouse, call accountant, and inter-domain OSP compatible gateway authorization agent. However, it is important to note that such a system only functions properly if both gateways are OSP compatible (i.e., they operate within an OSP compatible network).
In order for the gateways 120, 125 to be able to communicate properly with the OSP server 115 and other OSP gateways, each gateway must also be OSP compatible. For example, an OSP gateway must be able to analyze an OSP token received from either another gateway or the OSP server 115. Thus, the OSP gateway must be able to decode and decrypt (if necessary) the OSP token. The OSP gateway must be able to generate an authorization request to and read authorization replies from the OSP server 115. Also, the OSP gateway must be able to communicate properly with other OSP gateways in order to establish a call connection.
Typically, OSP gateways have software that enables these types of communications between OSP gateways and OSP servers. This software also contains call-monitoring functionalities such as call usage and authorization. As a result, OSP gateways are able to transmit this information back to an OSP server where it is stored and later retrieved for billing and other purposes. This requirement limits the number of gateways that may interface with the OSP server 115 and connect to other OSP gateways 120, 125.
One significant problem in existing VoIP networks is that there are a large number of non-OSP compatible networks and corresponding gateways currently in operation. These non-OSP networks may not participate in a VoIP connection implementing OSP or interface with an OSP server. Converting these non-OSP networks would require a large amount of work because of the number of different network owners currently in operation. Also, each non-OSP device (e.g., gateway) would need to have software installed that allows it to interface with OSP devices. Such an installation would be very costly due to the large number of non-OSP devices currently in operation and very difficult because of compatibility issues between different service providers. Thus, a user on an OSP network is limited to certain gateways and corresponding telephone numbers to which she/he may place a call using OSP.
It is also important to note that the connection 180 between the first and second OSP gateways 120, 125 is not particularly secure. Specifically, as described above, each gateway 120, 125 is aware of the other gateway's IP address. As a result of this gateway visibility, hackers may be able to access the gateways 120, 125 and the networks 160, 165 on which they reside.
Accordingly it is desirable to provide a voice bridge that allows non-OSP networks to interface with an OSP server and connect with both OSP and non-OSP networks. Additionally, it is also desirable to provide a voice bridge that provides IP masking to OSP gateways during communication.